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Abstract 


This memo creates a number of OSPF registries and provides guidance 
to IANA for assignment of code points within these registries. 
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Les 


Introduction 


This memo defines various OSPF registries for IANA to set up and 
maintain for OSPF code points. In some cases, this memo defines 
ranges of code point values within these registries; each such range 
has a different assignment policy. 


The terms used in describing the assignment policies are as follows: 
o Standards Action 
o Experimentation 
o Vendor Private Use 
o Reserved 


Standards Action means that assignments in that range MUST only be 
made for Standards Track RFCs (as defined in [RFC2434]). 


Some of the registries defined below reserve a range of values for 
Experimentation. For guidelines regarding the use of such values see 
[RFC3692]. Values from this range MUST NOT be assigned by IANA. 
Further guidance on the use of the Experimentation range may be found 
in paragraphs 4, 5, and 6 of [RFC3692]. An implementation MAY choose 
to not support values from the Experimentation range. In sucha 
case, the protocol data structure with a code point from the 
Experimentation range is ignored, unless other protocol machinery 
says how to deal with it. "Ignored" in this context means that the 
associated data structure is removed from the received packet before 
further processing, including flooding. 


Values set aside as Vendor Private Use MUST NOT be assigned by IANA. 
A protocol data structure whose code point falls in this range MUST 
have a disambiguating field identifying the Vendor. This identifier 
consists of four octets of the Vendor’s SMI (Structure of Management 
Information) enterprise code (see [ENTERPRISE-NUMBERS]) in network 
byte order; the location of this code must be well-defined per data 
structure. An implementation that encounters a Vendor Private code 
point SHOULD check whether the enterprise code is one that it 
recognizes; if so, the implementation MAY choose to interpret the 
code point and data structure. Otherwise, it SHOULD ignore the code 
point, unless the protocol machinery says how to deal with the data 
structure (as defined in the previous paragraph). This allows 
multiple vendor private extensions to coexist in a network. 


Values in the Reserved range MUST NOT be assigned until a Standards 
Track or Best Common Practices RFC is published defining the 
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assignment policy for that range. This RFC MUST be the product of 
the OSPF Working Group; if the OSPF WG is terminated, then it MUST be 
reviewed by an Expert Reviewer designated by the IESG. 

1.1. Conventions Used in This Document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 

2. OSPF Registries 
This section lists the various registries for OSPF protocol code 
points. Note that some of these are for OSPF, and some are specific 
to a particular version of OSPF; also, some registries predate this 
memo. 
Registries that are specific to one version of OSPF reflect the 
version number in the registry name (e.g., OSPFv2 Options). A 
registry whose name does not mention a version number applies to both 
OSPFv2 and OSPFv3 (e.g., OSPF Packet Type). 

2.1. OSPFv2 Options 


(Defined in Section A.2 of [RFC2328], updated in Section A.1 of 
[RFC2370]. See also [RFC3101].) 


Assignment policy: Standards Action. 
2.2. OSPFv3 Options 

(Defined in Section A.2 of [RFC2740]) 

Assignment policy: Standards Action. 
2.3. OSPF Packet Type (Both v2 and v3) 


(Defined in Section A.3.1 of [RFC2328]) 


+--------- +-------------------- + 
| Range | Assignment Policy | 
+--------- +-------------------- + 
| o | Not to be assigned | 
| 1-5 | Already assigned | 
| 6-127 | Standards Action | 
| 128-255 | Reserved 

+--------- +-------------------- + 
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2.3.1. OSPF Authentication Type 
(Defined in Section A.3.1 of [RFC2328]) 


(Note: this registry is called "OSPF AUTHENTICATION CODES" by IANA.) 


Yoo +------------------- + 
| Range | Assignment Policy | 
+------------- +------------------- + 
| 0-2 | Already assigned | 
| 3-247 | Standards Action | 
| 248-65519 | Reserved 

| 65520-65535 | Experimentation | 
Yoo +------------------- + 


2.4. OSPFv2 Link State (LS) Type 


(Defined in Section A.4.1 of [RFC2328]) 


Ho AZ Eea + 
| Range | Assignment Policy | 
+--------- AO + 
| o | Not to be assigned | 
| 1-11 | Already assigned | 
| 12-127 | Standards Action | 
| 128-255 | Reserved 

Ho $ AERAR nAn + 


If a new LS Type is documented, the documentation MUST say how the 
Link State ID is to be filled in, what the flooding scope of the LSA 
(Link State Advertisement) is, and how backward compatibility is 
maintained. 


2.4.1. OSPFv2 Router LSA Link Type 


(Defined in Section A.4.2 of [RFC2328]) 


Hai oO SSE + 
| Range | Assignment Policy | 
do dt A + 
es | Not to be assigned | 
| 1-4 | Already assigned | 
| 5-127 | Standards Action | 
| 128-255 | Reserved 

do $T + 


There is no range for Vendor Private Use, as there is no space for an 
enterprise code to identify the Vendor. 
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No Experimental range is defined, due to possible backwards 
compatibility issues. 


If a new Router LSA Link Type is documented, the documentation SHOULD 
say how the Link State ID, Link ID, and Link Data fields are to be 
filled in, and how backward compatibility is maintained. 

2.4.2. OSPFv2 Router Properties 
(Defined in Section A.4.2 of [RFC2328], updated in [RFC3101]) 


This 8-bit field in the Router LSA is unnamed; it is the field 
immediately following the Router LSA length. 


Assignment policy: Standards Action. 


2.5. OSPFv3 LSA Function Code 


This registry is created by [OSPF-CAP]. This document provides the 
values to be populated for values defined in Section A.4.2.1 of 
[RFC2740]. 


2.5.1. OSPFv3 Prefix Options 
(Defined in Section A.4.1.1 of [RFC2740]) 
Assignment policy: Standards Action. 
2.5.2. OSPFv3 Router LSA Link Type 


(Defined in Section A.4.3 of [RFC2740]) 


do a + 
| Range | Assignment Policy | 
do q S E E a + 
| o | Not to be assigned | 
| 1-4 | Already assigned | 
| 5-127 | Standards Action | 
| 128-255 | Reserved 

Ho he Se o + 


There is no range for Vendor Private Use, as there is no space for an 
enterprise code to identify the Vendor. 


No Experimental range is defined, due to possible backwards 
compatibility issues. 
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2.6. OSPFv2 Opaque LSA Type 
(Defined in Section A.2 of [RFC2370]) 


(Note: this registry is called "OSPF Opaque LSA Option" by IANA. See 
also [RFC3630].) 


+--------- +-------------------- + 
| Range | Assignment Policy | 
+--------- +-------------------- + 
| o | Not to be assigned | 
| 1-3 | Already assigned | 
| 4-127 | Standards Action | 
| 128-247 | Reserved 

| 248-251 | Experimentation | 
| 252-255 | Vendor Private Use | 
+--------- +-------------------- + 


In an OSPFv2 Opaque LSA with Opaque LSA Type in the Vendor Private 
Use range, the first four octets of Opaque Information MUST be the 
Vendor enterprise code. 


A document defining a new Standards Track Opaque LSA with TLVs and 
sub-TLVs MUST describe ranges and assignment policies for these TLVs. 


2.6.1. OSPFv2 Grace LSA Top Level TLVs 


(Defined in Appendix A of [RFC3623]) 


$ $2 O + 
| Range | Assignment Policy | 
$ $2 E + 
| o | Not to be assigned | 
13 Already assigned 
4-255 Standards Action 
| 256-65519 | Reserved | 
| 65520-65527 | Experimentation | 
| 65528-65535 | Vendor Private Use | 
$ $2 O + 


In a Grace LSA, if a top-level TLV has a Type from the Vendor Private 
Use range, the Length MUST be at least four, and the first four 
octets of the Value field MUST be the Vendor enterprise code. 
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3. Acknowledgments 


Many thanks to Adrian Farrel and Acee Lindem for their review and 
comments. 


4. Security Considerations 


The lack of adequate IANA guidelines may be viewed as an avenue for 
Denial of Service attacks on IETF protocols (in this case, OSPFv2 and 
OSPFv3), and on the IETF Standards Process in general. This memo 
attempts to close this loophole for OSPFv2 and OSPFv3. 


Authors contemplating extensions to OSPF SHOULD examine such 
extensions carefully, and consider whether new registries are needed, 
and if so, allocation policies within each registry. 


5. IANA Considerations 


This document specifies assignment policy for several existing IANA 
registries and creates several more. 


5.1. OSPFv2 Options Registry 


Section 2.1 defines the policy for allocation of bits from this 


registry as "Standards Action". There are only 8 bits in this field, 
and 6 are already assigned. The initial registry contents are given 
below. 


OSPFv2 Options Registry (Section 2.1) 


Value Description Reference 


0x02 E-bit [RFC2328] 
0x04 MC-bit [RFC1584] 
0x08 N/P-bit [RFC3101] 
0x10 Reserved 

0x20 DC-bit [RFC1793] 
0x40 O-bit [RFC2370] 


5.2. OSPFv3 Options Registry 
Section 2.2 defines the policy for allocation of bits from this 


registry as "Standards Action". There are 24 bits in this field, and 
6 are assigned. The initial registry contents are given below. 
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OSPFv3 Options Registry (Section 2.2) 


Value Description Reference 
0x000001 V6-bit [RFC2740] 
0x000002 E-bit [RFC2328] 
0x000004 MC-bit [RFC1584] 
0x000008 N-bit [RFC3101] 
0x000010 R-Bit [RFC2740] 
0x000020 DC-bit [RFC1793] 


5.3. OSPF Packet Type Registry 
Section 2.3 defines the policy for allocation of values from this 
registry for different ranges. The initial registry contents are 


given below. 


OSPF Packet Type (Section 2.3) 


Value Description Reference 
1 Hello [RFC2328] 
2 Database Description [RFC2328] 
3 Link State Request [RFC2328] 
4 Link State Update [RFC2328] 
5 Link State Ack [RFC2328] 


5.4. OSPF Authentication Type Registry 
This registry already exists at IANA, called "ospf-authentication- 
codes". Section 2.3.1 defines the policy for allocation from this 
registry for different ranges. 


5.5. OSPFv2 Link State Type Registry 


Section 2.4 defines the policy for allocations from this registry for 
different ranges. The initial registry contents are given below. 
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OSPFv2 Link State (LS) Type (Section 2.4) 


Value Description Reference 
1 Router-LSA [RFC2328] 
2 Network-LSA [RFC2328] 
3 Summary-LSA (IP network) [RFC2328] 
4 Summary-LSA (ASBR) [RFC2328] 
5 AS-external-LSA [RFC2328] 
6 Group-membership-LSA [RFC1584] 
7 NSSA AS-external LSA [RFC3101] 
8 Reserved 

9 Link-local Opaque LSA [RFC2370] 
10 Area-local Opaque LSA [RFC2370] 
11 Opaque LSA [RFC2370] 


5.6. OSPFv2 Router LSA Link Type Registry 


June 2007 


Section 2.4.1 defines the policy for allocations from this registry 
for different ranges. The initial registry contents are given below. 


OSPFv2 Router LSA Link Type (Section 2.4.1) 


Value Description Reference 
1 Point-to-Point connection to another router [RFC2328] 
2 Transit Network [RFC2328] 
3 Stub Network [RFC2328] 
4 Virtual Link [RFC2328] 


5.7. OSPFv2 Router Properties Registry 


Section 2.4.2 defines the policy for allocation of bits from this 
registry as "Standards Action". There are only 8 bits in this field, 
and 5 are already assigned. The initial registry contents are given 


below. 
OSPFv2 Options Registry (Section 2.1) 


Value Description Reference 


0x01 B-bit [RFC2328] 
0x02 W-bit [RFC2328] 
0x04 V-bit [RFC2328] 
0x08 W-bit [RFC1584] 
0x10 Nt-bit [RFC3101] 
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5.8. OSPFv3 LSA Function Code Registry 


This registry is created by [OSPF-CAP], which also defines the 
registration policy. This section contains values that belong in 
this registry that were defined by [RFC2740]. 


As defined in [RFC2740], the first 3 bits of the LSA Function 
Code are the U, Sl, and S2 bits. A given function code implies a 
specific setting for the U, S1, and S2 bits as shown in the "LS Type" 
column. 
le diss AIS ell. tly. cL 
Ox L 2 3. -4> 5.6 T 88> 39°70). als 42y 3 a> 5 
+--+--4+--+--4+--+--4+--4+--+4+--4+--+--4+--+--4+--+--+--+ 
|u |s2|s1| LSA Function Code 
+--+--4+--+--4+--+--4+--+--+--4+--+--4+--+--4+--+--+--+ 


The U bit indicates how the LSA should be handled by a router which 
does not recognize the LSA’s function code. Its values are: 


U-bit LSA Handling 


0 Treat the LSA as if it had link-local flooding scope 
1 Store and flood the LSA, as if type understood 


The S1 and S2 bits indicate the flooding scope of the LSA. The 
values are: 


s1 S2 Flooding Scope 

Link-Local Scoping. Flooded only on link it is originated on 
Area Scoping. Flooded to all routers in the originating area 
AS Scoping. Flooded to all routers in the AS 

Reserved 


The initial registry contents are given below. 
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OSPFv3 LSA Function Code (Section 2.5) 


LSA Function Code LS Type Description Reference 
1 0x2001 Router-LSA [REC2740] 
2 0x2002 Network-LSA [REC2740] 
3 0x2003 Inter-Area-Prefix-LSA [RFC2740] 
4 0x2004 Inter-Area-Router-LSA [RFC2740] 
5 0x4005 AS-External-LSA [REC2740] 
6 0x2006 Group-membership-LSA [RFC2740] 
7 0x2007 Type-7-LSA [RFC2740] 
8 0x0008 Link-LSA [RFC2740] 
9 0x2009 Intra-Area-Prefix-LSA [RFC2740] 


5.9. OSPFv3 Prefix Options Registry 


June 2007 


Section 2.5.1 defines the policy for allocation of bits from this 
registry as "Standards Action". There are only 8 bits in this field, 
and 4 are already assigned. The initial registry contents are given 


below. 
OSPFv3 Prefix Options Registry (Section 2.5.1) 


Value Description Reference 


0x01 NU-bit [RFC2740] 
0x02 LA-bit [RFC2740] 
0x04 MC-bit [RFC2740] 
0x08 P-bit [RFC2740] 


5.10. OSPFv3 Router LSA Link Type Registry 


Section 2.5.2 defines the policy for allocations from this registry 
for different ranges. The initial registry contents are given below. 


OSPFv3 Router LSA Link Type (Section 2.5.2) 


Value Description Reference 

1 Point-to-Point connection to another router [RFC2740] 

2 Transit Network [RFC2740] 

3 Reserved [RFC2740] 

4 Virtual Link [RFC2740] 
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5.11. OSPFv2 Opaque LSA Type Registry 


June 2007 


This registry already exists at IANA, called "ospf-opaque-types". 
Section 2.6 defines the policy for allocation from this registry for 


different ranges. 


5.12. OSPFv2 Grace LSA Top Level TLV Registry 


Section 2.6.1 defines the policy for allocations from this registry 
for different ranges. The initial registry contents are given below. 


OSPFv2 Grace LSA Top Level TLV (Section 2.6.1) 


Value Description Reference 
1 Grace Period [RFC3623] 
Z Graceful Restart reason [RFC3623] 
3 IP Interface Address [RFC3623] 
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